= Сообщение: 10034 из 10753 ==================================== RU.UNIX.BSD = От : Dmitry Dolzenko 2:5020/400 14 Oct 20 14:06:58 Кому : Eugene Grosbein 14 Oct 20 14:06:58 Тема : Re: Аварийный вход в LAN через сотовый модем FGHI : area://RU.UNIX.BSD?msgid=<1187514739@ddt.demos.su>+af6196e4 На : area://RU.UNIX.BSD?msgid=grosbein.net+596ce57a = Кодировка сообщения определена как: IBM866 ================================= ============================================================================== From: Dmitry Dolzenko <dol@mig.phys.msu.ru>
28.09.2020 10:42, Eugene Grosbein пишет: > 26 сент. 2020, суббота, в 14:03 NOVT, Dmitry Dolzenko написал(а): > > DD> Арендую VPS, к нему сделаю туннель через tp-link, и резервный mx на этом > DD> VPS с пропихиванием почты в случае чего по vpn тоннелю на основной MX. > > Вообще конкретно с SMTP это не особая проблема, потому что очереди > на доставку есть у всех серверов отправителей, в крайнем случае > почта полежит там, при условии что у тебя зарезервирован DNS. > > А если не зарезервирован DNS, ты хоть делай себе доступный резервный MX, > хоть не делай - почта на него даже не пойдет. > > И, допустим, ты сделал себе резервный MX и он принимает почту и льёт > её через резервный канал поверх LTE. А LTE идёт через операторские соты и > конкурирует за полосу с другими клиентами оператора, которые смотрят > футбол на ютубчике или киношечки. И вполне может случиться так, > что почта с резервного MX тебе станет забивать доступную тебе ширину. > > А кроме того, ты очень быстро столкнёшься с тем фактом, > что спамеры очень любят слать спам через низкоприоритетные > (резервные) MX вместо основного, даже когда основной нормально > доступен, потому что наивно настроенный резервный MX легче > принимает всякий мусор. Hапример, основной MX может сразу отбивать > почту на несуществующие локальные ящики, а резервный MX > может принимать на любые адреса домена, затем при попытке доставки > на основной сервер получит отлуп из-за несуществования имени, > так что будет сгенерирован DSN на скорее всего подставной > адрес отправителя и твой резервный MX отправит спам-письмо > в виде возврата невинной жертве. За такое ты сам быстро попадёшь > в черные списки. > > Это можно пытаться решить с помощью milter-ahead (в случае sendmail) > или ещё каких наворотов, но я бы вообще сильно не парился > созданием резервного MX для LTE, почта спокойно полежит в очередях > серверов отправителей. А вот вторичный внешний DNS завести обязательно. > > DD> Плюс скрипт на основном роутере конторы, который переключает роутинг в > DD> случае проблем на tp-link. > DD> Есть еще нерешенная проблема с вебсервером конторы, который не виден в > DD> случае падения канала. > DD> Первое что приходит на ум - поставить на VPS nginx в режиме reverse > DD> proxy с работой по 2 каналам. В случае падения основного переключение на > DD> резерв. > DD> Или может есть способ лучше? > > Обратный прокси на VPS добавит тебе заметных задержек при обращении > к сайту, а интерактивный HTTP(S) к задержкам чувствителен. > > Да, есть способ лучше - подключить второго оператора фиксированной связи :-) > Это, кстати, кардинально решает проблему с почтой и с DNS: > почта будет приходить по "резервной" записи MX реально на основной > почтовый сервер, и DNS будет зарезервирован так же второй записью NS. > > А сайт можно вообще вынести на внешний хостинг. > Качественное резервирование без затрат скорее утопия. > > Eugene
Да, сайт надо на внешний хостинг, ты прав.
По поводу второго оператора, тут ничего не выходит, это госучереждение, и там _нельзя второго оператора_ . Поэтому и приходится заморачиваться с LTE.
По поводу почты - при падении канала ее критично важно получать и отправлять, поэтому вариант с лежанием в очереди не подходит.
А если на резервном VPS 25 порт пробросить через туннель на основной почтовый сервер какой то затычкой. Может тем же ipfw получится?
IP_VPS:25 ---vpn ---- IP_MAILSERV:25
это не решит проблему с валом отбойников?
/D --- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
